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IPv4 Service Continuity Prefix 

Abstract 
Dual-Stack Lite (DS-Lite), defined in RFC 6333, directs IANA to 
reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element. 
Per this memo, IANA has generalized that reservation to include other 
cases where a non-routed IPv4 interface must be numbered as part of 
an IPv6 transition solution. 
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1. Introduction 


DS-Lite [RFC6333] directs IANA to reserve 192.0.0.0/29 for the Basic 
Bridging BroadBand (B4) element. This memo generalizes that IANA 
reservation to include other cases where a non-routed IPv4 interface 
must be numbered in an IPv6 transition solution. IANA has listed the 
address block 192.0.0.0/29 reserved for IPv4 Service Continuity 
Prefix. The result is that 192.0.0.0/29 may be used in any system 
that requires IPv4 addresses for backward compatibility with IPv4 
communications in an IPv6-only network but does not emit IPv4 packets 
"on the wire". 


This generalization does not impact the use of the IPv4 Service 
Continuity Prefix in a DS-Lite context. 


2. Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. The Case of 464XLAT 


464XLAT [RFC6877] describes an architecture for providing IPv4 
communication over an IPv6-only access network. One of the methods 
described in [RFC6877] is for the customer-side translator (CLAT) to 
be embedded in the host, such as a smartphone or a CPE (Customer 
Premises Equipment). In such scenarios, the host must have an IPv4 
address configured to present to the host network stack and for 
applications to bind IPv4 sockets. 
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4. Choosing 192.0.0.0/29 


To avoid conflicts with any other network that may communicate with 
the CLAT or other IPv6 transition solution, a locally unique IPv4 
address must be assigned. 


IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333], 
which is dedicated for DS-Lite. As defined in [RFC6333], this subnet 
is only present between the B4 and the Address Family Transition 
Router (AFTR) and never emits packets from this prefix "on the wire". 
464XLAT has the same need for a non-routed IPv4 prefix, and this same 
need may be common for other similar solutions. It is most prudent 
and effective to generalize 192.0.0.0/29 for the use of supporting 
IPv4 interfaces in IPv6 transition technologies rather than reserving 
a prefix for every possible solution. 


With this memo, 192.0.0.0/29 is now generalized across multiple IPv4 
continuity solutions such as 464XLAT and DS-Lite. A host MUST NOT 
enable two active IPv4 continuity solutions simultaneously in a way 
that would cause a node to have overlapping 192.0.0.0/29 address 
space. 


5. Security Considerations 


There are no new security considerations beyond what is described 
[RFC6333] and [RFC6877]. 


6. IANA Considerations 


IANA has updated the IPv4 Special-Purpose Address Registry available 
at (http://www.iana.org/assignments/iana-ipv4-special-registry/) as 


follows: 

OLD: 

192.0.0.0/29 DS-Lite [RFC6333] 

NEW: 

192.0.0.0/29 IPv4 Service Continuity Prefix [RFC7335] 
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t-------- 55 Pe Sse 5 SSeS a8 SSeS e + 
| Attribute | Value 
E E === E A a N E R + 
| Address Block | 192.0.0.0/29 | 
| Name | IPv4 Service Continuity Prefix | 
| RFC | RFC 7335 | 
| Allocation Date | June 2011 
| Termination Date | N/A 

Source True 

Destination True 
| Forwardable | True 
| Global | False | 
| Reserved-by-Protocol | False 
enen a a 5 A EE E E A + 
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